A mainframe can host a software application programmed to manage an output stream, as the output stream is generated, while remaining agnostic as to an origin of the output stream. Resultantly, the software application can be programmed to automate report data capture, archiving, retrieval, or destruction, based on the output stream and a set of rules for each type of output stream.
When the software application is an Enterprise Output System (EOS) software application, as provided by RSD America Inc.®, then this software application is implemented as a series of continuously running programs (started tasks) which need to be monitored, and are complicated to administer due to presence of many environments within the EOS, a multitude of different configuration settings within each environment, synchronization of configuration settings across environments, security settings for thousands of users, and handling of many data inputs/outputs. Therefore, various misconfigurations/errors may arise. Likewise, such complexity is difficult to administer, which leads to greater resource use, greater expense, and a higher error rate for configuration changes made. Similarly, such complexity entails that an administrator of the EOS application be experienced/proficient, which is not always possible.
Examples of technical problems resulting from manually administering the EOS are numerous. Some of such examples include failed ingest jobs caused when a user requests a modification to an EOS form index, which occurs while a job, written in Job Control Language (JCL), is ingesting a multi-part report into the EOS. As such, the ingestion will fail because the form index is being modified in the EOS. Further, some of such examples include lack of monitoring of the many started tasks within the EOS because manually doing so is time consuming and complicated since few resources are dedicated and skilled enough to do such monitoring on a regular basis. Therefore, various undesired events or delays can occur in the EOS without notice, which may be expensive to repair at that time. Moreover, some of such examples include the EOS making use of a large number of model JCLs that are executed on a regular basis. When massive or voluminous changes need to be made to these model JCL's, and these changes are manually made, then there is a likelihood that a particular component of the EOS application may fail due to a mistake within these model JCL's. Additionally, some of such examples occur when a new report is manually defined to an EOS form index file, and then the changes have to also be replicated to similar test environments. Human errors from performing this repetitious work, such as digit transposition or setting misconfiguration result in failures to successfully ingest instances of these new reports in those environments. Also, some of such examples occur when some activities are done in administration of EOS metadata using tools supplied by the EOS and various details in various activity logs are not sufficient. This insufficiency complicates remedial research for various administrative actions that caused a user problem. Furthermore, some of such examples occur because the EOS is complex and can be used in various technical environments. As such, the administrator can build subject matter expertise and efficient workflow over a long time period. In addition, some of such examples result from the EOS running 24/7 and the administrator or an expert in the EOS may not be available when needed, and various users must suffer from a lack of use of the EOS until the administrator or the expert can be located to fix. Accordingly, there is a desire for a computing technology to address at least one of such technical challenges.